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REMARKS 

Status of this application 

In the Office Action mailed on August 23, 2005 : 

claims 1-18 were rejected xmder 35 U.S.C. §101 for "nonstatutory double 
patenting; 

claims 1-1 8 were rejected under 35 U.S.C. §101 because the recitation of an 
"application program" was deemed to '^on-statutory as not being 
tangible;" 

claims 1-1 8 were rejected under 35 U,S,C. §1 12 on the basis that the transmission 
of data to an internet address as recited in claims 1, 8 and 12 was deemed 
to be inadequately described in the specification; 

claims 1-5 and 8-16 were rejected xmder 35 U.S.C. §103 (a) as being unpatentable 
over Meltzer et al. Patent 6,542,912 (hereinafter "Meltzer") and further in 
view of Call Patoit 6^154,738 (hereinafter the "Call Patent"); and 

claims 6-7 and 17-18 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Meltzer and the Call Patent as appUed to claims 1-5 and 8-16 above, 
and ftirther in view of Walker et al. (hereinafter 'Walker''), US Patent No. 
6,041,308. 

This response amends claim 1 to correct internal antecedent references in the claim. This 
response fiirther requests reconsideration of the "obviousness" rejections of claims 1-18 for the 
reasons stated below. The following comments treat the above-noted rejections in the order 
stated in the outstanding Office Action. 

The Double Patenting Rejection 

Claims 1-18 were provisionally rejected under 35 U.S.C. 101 as claiming the same 
invention as that of claims 29-36 of co-pending Application No. 10/120,175, a division of the 
pnresent application. Although ^plicant does not concede that the claims in this application and 
in the above-identified division of this a^phcation are not patentably distinct from each other, 
applicants are filing herewith a terminal disclaimer in compliance with 37 CFR 1 .321 (c) as 
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suggested by the Examiner to overcome this rejection. Oracle Intemational Corp. is the owner of 
record of both this application and the above-identified division of this application. 

The Non-Statntorv Subject Matter Rejection 

Claims 1-18 were rejected under 35 U.S.C. 101 because, as stated in paragraph 5 of the 
Action, "an 'application program' to perfomi the method of claims 29-36 is non-statutory as not 
being tangible," Since there are no claims numbered 29-36 in the present application, it is likely 
that that the Examiner's rejection of claims 1-18 resulted from a review of claims 29-36, the 
pending claims of the divisional application upon which the double patenting rejection was 
based, and was included in this Action inadvertently. 

In any case, reconsideration is requested. The rejected claims 1-18 as a whole are 
directed to methods and apparatus for performing computer-related processes that are limited to 
practical applications in the technological aits and which produce a concrete, tangible and useful 
result: permitting executing application programs to obtain and process information obtained via 
the Intemet fix>m identified remote resources using a standard API that serves such application 
programs. That is all that section 101 requires. As stated at §21 06, part IV(A), of the Manual of 
Patent Examining Procedure: 

"As the Supreme Court has held. Congress chose the expansive language of 35 
U.S.C- 101 so as to include "anything under the sun that is made by man." Diamond v. 
Chakrabarty, 447 U.S- 303, 308-09, 206 USPQ 193, 197 (1980). Accordingly, section 
101 of title 35, United States Code, provides: Whoever invents or discovers any new and 
usefiil process, machine, manufacture, or composition of matter, or any new and useful 
improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. In Chakrabarty, 447 U.S. at 308-309, 206 USPQ at 197, the 
court stated: In choosing such expansive terms as "manufacture" and "composition of 
matter," modified by the comprehensive "any,** Congress plainly contemplated that the 
patent laws would be given wide scope. 

^ * 3» 
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'This perspective has been embraced by the Federal Circuit: The plain and 
unambiguous meaning of section 101 is that any new and useM process, machine, 
manufacture, or composition of matter, or any new and useful improvement thereof, may 
be patented if it meets the requirements for patentabihty set forth in Title 35, such as 
those found in sections 102, 103, and 112. The use of the expansive term "any" in section 
101 represents Congress *s intent not to place any restrictions on the subject matter for 
which a patent may be obtained beyond those specifically recited in section 101 and the 
other parts of Title 35. * * * Thus, it is improper to read into section 101 limitations as 
to the subject matter that may be patented where the legislative history does not indicate 
that Congress clearly intended such lunitations. Alappat, 33 F3d at 1542, 31 USPQ2d at 
1556." 

The "application programs" referred to claims 1-18 of this application are '^tangible." As 
is well imderstood, application programs, indeed all computer programs, consist of instructions 
that are recorded in physical media which are accessed by and control the operation of a physical 
processor that, executes those instructions. The Examiner has cited no authority of the 
proposition that referring to a computer program as an element in an apparatus claim, or as 
something that participates in a claimed process, renders the claim unpatentable under Section 
101. 

The Lack of Enablement Rciecttoii 

Claims 1-18 were rejected imder 35 U,S,C. 1 12» first paragr^h, as failing to comply with 
the enablement requirement. Hie Examiner noted thai claims 1, 8 and 12 specify "an Intemet 
address to which an output information request directed to said givOT data resource may be 
transmitted" and "transmitting said reforaiatted request to the Intemet resource address", which 
were not described in the specification in such a way as to enable one skilled in the art to which 
it pertains, or with which it is most nearly connected, to make and/or use the invention." 

Reconsideration is requested. The basic mechanism involving the claimed *Thtemet 
address is set forth in the Summary of the Invention at pages 3-4 of applicants' specification as 
follows: 
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In a principle aspect, the present invention takes the form of methods and 
apparatus for obtaining information from each of a plurality of diverse data resources 
having different characteristics. A separate service description for each given data 
resource is stored in a database called the Services Registry. Each service description 
includes: the address to which an information request may be transmitted: a specification 
of the natin-e of the input information to be supplied; and a description of the nature of the 
output information to be supplied in response to request. 

Service requests identifying particular resources may be issued by application 
programs. A service interface program is then executed in response to each such service 
request to obtain the particular service description corresponding to the identified 
resource from the Services Registry. The interface program then transmits an output 
information request to the address specified in said particular service description, supplies 
input information meeting the specification contained in said particular service 
description to the resource, and routes output information provided by said particular 
resource to the requesting application program. 

As explained, for example, at page 11, lines 6-15, the "Internet address** which is stored 
in each services description may, in a common scenario, take the form of a specific URL that is 
used in an HTTP Get or Put method to transmit an output information request to the Internet 
address specified by the stored URL. It is submitted that expressing an Intemet address as a URL 
and then transmitting formatted request messages to that URL ^e common techniques which 
form the basis for the HTTP request-response protocol, the fundamental mechanism used for 
most data exchanges which take place in the World Wide Web and other services. The 
Examiner's suggestion that the description provided by the specification would be inadequate to 
explain to one sktQed in the art what the address (URL) is and how to use it is simply incorrect. 

Moreover, the Examiner has failed to explain or establish any reasonable basis for 
questioning the adequacy of the disclosure. As stated in the M J.E,P. at §2106.01 : 

''When basing a rejection on the failure of the applicant's disclosure to meet the 
enablement provisions of the first paragraph of 35 U.S.C. 112, the examiner must 
establish on the record that he or she has a reasonable basis for questioning the adequacy 
of the disclosure to enable a person of ordinary skill in the art to make and use the 
claimed invention Avithout resorting to undue experimentation. See In re Brawn^ All F.2d 
946, 177 USPQ 691 (CCPA 1973); In re Ghiron, 442 F.2d 985, 169 USPQ 723 (CCPA 
1971)." 
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Reconsideration of the rejection of claims 1-18 based on the alleged inadequacy of the 
disclosure of the claimed Internet address and the transmission of a request message to that 

i 

address is requested. 

Claim Rejections - 35 USC $ 103 

Claims 1-5 and 8-16 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Meltzer in view of the Call Patent. The Examiner contends that the subject matter set forth in 
claims 1 and 12 is anticipated by Meltzer, with the exception that the Examiner acknowledges 
that Meltzer does not explicitly disclose '^producing an information request message that includes 
said input information" or "transmitting said information request message to the Intemet address 
included in said particular service description" as set forth, for example, in claim 1. The 
Examiner asserts however, that because Meltzer and the Call Patent both describe systems in 
which information is exchanged between man\ifacturers and distributors and retailers, it would 
have been obvious to modify Meltzer' s system to include a mechanism taught by the Call Patent 
for transmitting a request message to an Intemet address. 

Reconsideration is requested. Applicants claim a service interface program that receives 
requests for information via an application program interface from an application program. The 
received request specifies a particular resource. The interface program then retrieves a particular 
service description that corresponds to that particular resource. The interface program then 
processes input data obtained from the requesting appHcation program to produce a request 
message. The interface program then transmits the resulting request message to an Intemet 
address that is contained in the particular service description previously retrieved. Finally, the 
interface program processes the raw response data supplied by the particular resource in response 
to the transmitted request message to create a reformatted response which is routed to the 
requesting application program. 

Metzger does not disclose or suggest such an interface program for the reasons which 
will be explained in detail the following specific remarks. Some of the leading differences may 
^' be briefly sinnmarized as follows: 

(I) Applicants* invention as claimed establishes an API that is interposed between 

requesting application programs and the Intemet, whereas Meltzer' s 
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"interface" is interposed between the Internet and each service provider host 
that performs transaction processing. 

(2) Applicants' service descriptions define the form of input data that is suppHed 
to the service interface program by application programs and the form of the 
output data that is returned from the service interface program to the 
application programs, whereas Meltzer*s interface defines the format of 
standard business XML documents that are exchanged via the Internet 
between trading partners. 

(3) Applicants' interface program exchanges data via the Internet in whatever 
format is normally used by each particular resource, but exchanges data with 
requesting application programs in a format specified by the service 
description of each resource. In contrast, Meltzer's interface programs are 
selected based on the detected type of each incoming XML document that is 
supplied via the Internet in a standard format, and Meltzer's interface 
programs then perform transaction processing to generate output XML 
documents in a standard form that are returned via the Internet to the trading 
parmer that supplied the input document. 

(4) Applicants' interface programs as claimed accept a resource designation, 
retrieve a service description corresponding to the designated resource, and 
then create and transmit a request message to an Internet address contained in 
the received service description. As acknowledged by the Examiner, Meltzer 
does not describe a mechanism for creating a request message that includes 
ic5>ut data accepted form an appUcation program^ and for then sending that 
request message to an Internet address contained in retrieved service 
description. Although the Examiner asserts that incorporating that claimed 
function could have been added to the Meltzer system in a way that would 
have been obvious in view of the Call Patent, there is nothing in either 
reference that justifies such a conclusion. 

(5) Applicants' interface programs as claimed process the raw response data 
received via the Internet from the particular remote resource in accordance 
with a processing specification defined in the retrieved service description and 
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then routes a reformatted response to the requesting application program. In 
contrast, Meltzer's interface program processes input docimients in standard 
form specified by the service description that are received via the Ihtemet to 
create output documents in standard form that are returned via the Internet. 

As pointed out by the Examiner, Metzler describes a service description database that 
includes "service descriptions" (called business interface definitions or "BIDs") at col. 10, lines 
32-54. These BIDs have a layout depicted in Fig. 2 and define, for each interface, among other 
things, the standard fomiat for the input document or documents (at 21 1) which are received via 
the Intemet and processed by the service provider, the standard format for the output document 
or documents (at 212) returned by the service provider via the Intemet, and the network location 
where the service is performed (at 209). But this BID data is employed by the Meltzer system to 
define the Intemet interface to each registered service provider, and not to define the data 
received from and supplied to an apphcation program from service interface program that 
performs the functions claimed by applicants. 

As discussed in detail below, Meltzer fails to disclose a service interface program that 
performs the functions set forth in independent claims 1 , 8 and 12, and the passages cited by the 
Examiner do not support the conclusions expressed in the outstanding OfGce Action. 

The Examiner suggests that Meltzer teaches an interface program that receives a service 
request identifying a particular resource from an executing application program and then obtains 
a service description corresponding to the particular resource, citing col. 19, lines 16-40 of 
Meltzer. However that cited passage describes the process of building a BID by gathering the 
data it stores, and nothing in that cited passage says anything about an interface program that 
receives a service request firom an application program that identifies a resource and the retrieves 
a corresponding service description. The Meltzer program that is used to build a GID described 
in the cited passage of col. 19 fails to perform any of the recited functions which the claimed 
interface program is required to perform by the claims. 

The Examiner next suggests that, at col. 3, lines 4-58, Meltzer teaches an interface 
program that obtains input information firom an executing application program that conforms to 
the input specification contained in a retrieved particular service description. While Meltzer 
does describe a remote services program that receive input information (one or more standard 
XML input documents) via the Intemet firom a remote trading partner (which may submitted by 
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an executing application program), Meltzer does not do this in the sequence claimed. Meltzer 
receives the input document, determines its type, and then processes the input document using 
routines that are established to conform to the service description. Nowhere does Meltzer 
suggest that an executing application program first issues a service request that identifies a 
particular resource, and that an interface program then processes that service request by 
retrieving a service description fix)m a database and thereafter obtains input information from the 
requesting application that conforms to the input processing specification contained in the 
received service description. 

The Examiner cites the passage at coL 24, fine 56 to coL 25 line 5 of Meltzer which 
describes how the service provider receives a standard input document via the Litemet, parses it 
to identify the service type requested, translates the incoming document into a native format for 
processing by transaction processing routines registered for handling incoming documents of that 
type, and then retums the resulting output data via the Internet as a standard XML output 
document. This passage does not describe an interface program that first receives a service 
request fiom an executing application that identifies a particular resource, then retrieves a service 
description, then obtains input information from the requesting application, and then creates a 
request-message that is sent via the Internet to the Intemet address of the particular resource 
contained in the retrieved service description, as required by all of the claims. 

The Examiner concedes that Meltzer does not describe an interface program that 
produces a request message in the manner claimed nor does Meltzer transmit such a request 
message via the Intemet to an Intemet address contained in the service description. Instead, 
Meltzer identifies the requested service fiiom the content of the received standard input document 
and then processes the input document using locally executed routines for handling input 
docimients of the type received. 

But the Examiner suggests that Meltzer' s mechanism could be modified in some 
unspecified way in view of the teachings of the Call Patent. Reconsideration is requested. 

At this point, ^plicants' undersigned attomey acknowledges that it is indeed a "small 
world," that he is the same "Charles G. Call" that is the named inventor of the system described 
in the cited Call patent, and that he is accordingly familiar with its teaching. 

The Examiner's characterization of the Call Patent is correct, but the Examiner does not 
explain how one skilled in the art would be led to modify the Meltzer system in view of its 
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teachings. Meltzer describes a system for performing transactions between trading partners by 
exchanging standard XML documents which have a form defined in discoverable '^business 
interface definitions." The Call Patent describes a way in which information about a product 
designated by a universal product code can be obtained via the Internet through the use of an 
Internet accessible cross-referencing facility, such as the domain name system, that can convert 
an available product code into the Internet address from which information about that product 
can be obtained. 

The Examiner states that "it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Call and Meltzer to include 
transmitting said reformatted request to the Intemet resource address and receiving a raw 
response via the Intemet. But the claim requires that the reformatted request message be created 
by an interface program that receives a request from an executing application program that 
designates a particular resource, and the interface program the retrieves a service description, and 
then obtains input infomiatlon from the requesting application in accordance with an input 
processing specification, and thereby creates the reformatted request message that is sent via the 
Intemet. The Examiner concedes Meltzer does not disclose creating a reformatted request in the 
manner claimed, and does not specify how or why the Call Patent's teaching might be employed 
to modify Meltzer's system to yield the subject matter claimed. 

In Meltzer*s system, business docimients having a standard form are exchanged between 
trading partners who use the document formats and the network addresses published in the 
business interface definitions. There appears to be no reason why one skilled in the art would be 
led to modify tfie Meltzer system to use the Call Patent's teaching, and the Examiner does not 
explain how or why one skilled in the art migjit modify Meltzer' s system in accordance with the 
Call Patent to yield the subject maXXer claimed. 

Reconsideration of the rejection of claims 1-5 and 8-16 based on the proposed 
combination of Meltzer and the Call Patent is accordingly requested since Meltzer does not 
disclose an interface program that performs the claimed functions, and because there is nothing 
in the Call Patent that woxild suggest a modification of the Meltzer trading system that would 
yield the claimed interface program. 

The Examiner fiirth^ rejected claims 6-7 and 17-18 as being unpatentable over Meltzer 
and the Call Patent as applied to claims 1-5 and 8-16 above, and further in view of Walker. 
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These dependent claims further recite that the service description contains additional infonnation 
that can be used to verify that the system is operating correctly and that requests are being issued 
from authorized sources before those requests are satisfied. The Examiner concedes that Meltzer 
and the Call Patent do not describe these additional features, but cites Walker in support of the 
contention that these additional features would have been obvious. Reconsideration is requested. 

With respect to claims 6 and 17 which claim storing a fixed input value and a fixed 
output value in the service description to test the system, the Examiner cites the teaching of 
Walker in which a test is performed to see if a purchase offer is accepted or rejected. It is not 
clear how this test might be incorporated into the Meltzer system, but if it were it would plainly 
not meet the limitations stated in claims 6 and 7. Walker does not teach storing fixed input and 
output values in a service description, sending the input value in a request message, and 
comparing the resulting output value with the stored output value as claimed. The rejection of 
claims 6 and 17 based on Walker should be withdrawn. 

With respect to claims 7 and 18 based on Walker*s teaching of encrypted transactions for 
security, it is submitted that one skilled in the art might indeed use a variety of well known 
security techniques such as encrypted transmissions to improve the security of Meltzer*s 
transactions, but that does not make it obvious to modify Meltzer by placing secxmty information 
in a service description to insure that requests are not responded to if they are found to come 
from an -unauthorized source. There is thus nothing in the Walker patent that suggests the 
subject matter specifically claimed in claims 7 and 18. 

Conclpsion 

Reconsideration and allowance of claims 1-18 as now presented is requested for the 
reasons presented above. 



Dated: December 23, 2005 
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Certiflcate of Transmission under 37 CFR 1-8 

I hereby certify that this amendment, a petition for a time extension, and a credit card 
payment form are being transmitted by facsimile to the central facsimile number of the U.S. 
Patent and Trademark OfBce, (571) 273-8300, on December 23, 2005. 

Dated: December 23, 2005 Signature C^^^^'tJ'^^^^ 

Charles G. Call, Reg. No. 20,406 

USPTO Customer No. 021253 

68 Horse Pond Road 

West Yamiouth, MA 02673 

Ph. (508) 778''2630 Fax (508) 629-6540 

call@patentsofl.com 
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